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METHOD AND SYSTEM OF IMPLEMENTING A CARRIER MANAGER 
REGISTRY 

The present invention relates to computerized logistics systems and, 
more particularly, to a system and method of rating items to be shipped by a 
selected carrier from among a plurality of carriers. 

In this specification, the term "OCX" is used, which is explained as 
follows. OLE™ and Active X™ controls, which are supported by Microsoft 
Corp., are representative of an object oriented programming environment. 
The general environment is labelled in the programming art as "OCX". The 
OCX control environment allows for late binding of function calls, remote 
execution in a distributed or networked environment, and interface with the 
Internet or World Wide Web. The OCX acts as an exchange facility to 
facilitate object oriented linking of diverse applications. Linking is 
accomplished by initiating a query at an application. The OCX control 
environment creates (or simply maintains as the case may be) a running 
object table for managing the objects to be created by the data link with the 
client applications. The method to be described hereinbelow then advances 
to where the OCX registers its ability to control the linked applications by 
creating a discrete object within the running object table that is 
representative of the control. 

Reference is made to United Kingdom Patent Application 

(Agent's reference P13034), entitled CARRIER MANAGER INTERFACE 
UTILIZING AN OCX CONTROL, United Kingdom Patent Application 

(Agent's reference P13033), entitled A METHOD AND 

SYSTEM FOR ACCESSING CARRIER DATA, United Kingdom Patent 

Application (Agent's reference P13035), entitled A METHOD 

AND SYSTEM FOR CHANGING RATING DATA VIA INTERNET OR 
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MODEM IN A CARRIER MANAGEMENT SYSTEM, and United Kingdom 

Patent Application (Agent's reference P13036), entitled A 

METHOD AND SYSTEM OF IMPLEMENTING A CARRIER MANAGER 
LIBRARIAN, all filed on even date herewith. 

A shipping carrier is a company that provides shipping services for 
letters, packages, bulk goods, or any other item to be shipped. Carriers can 
perform a variety of shipping services. For example, they can deliver 
express shipments, e.g. airmail for letters and second-day air for small 
packages. Moreover, carriers can deliver ground shipments for packages, or 
"LTL" shipments for bulk goods. The term "LTL" means "Less Than 
Truckload" and applies to any ground carrier shipment of standard 
commodities, for example, rated in units of hundreds of pounds. Shipments 
of bulk goods or standard commodities usually occupy a portion of a truck 
trailer, hence "less than truckload", but may require an entire truckload, 
occasionally known as "TL" shipments. 

Each carrier has its own rate structure for charging shippers for 
transporting their goods. Typically, these rates structures are complex and 
involve a variety of factors. For example, carriers often charge different 
prices by weight, sometimes with different weight classifications. As another 
example, carrier rates may be dependent on the distance to the destination. 
In addition, some carriers charge a premium for shipping classes, e.g. first 
class and second class, with shorter or longer guaranteed delivery times. In 
some cases, carriers may grant discounts for volume. Thus, the business 
rules for rating items to be transported varies greatly from carrier to carrier. 
These rating calculations may change over time for a particular carrier as its 
rates and business rules are updated. Accordingly, it is desirable to provide 
mechanisms for logistics systems for shipping goods to facilitate updating 
how carrier rates are calculated. 
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According to one approach, the carrier rate information and business 
rules are isolated into separately executable programs on a per-carrier basis. 
Thus, updating a carrier rating program can occur independently of other 
carrier rating programs. For example, U.S. Patent No. 5,631 ,827 issued May 
20, 1997 to Nicholls et al. describes a logistics system in which carrier rate 
information and business rules are isolated into separate program objects, 
called "rate servers." These rate servers are spawned by a client process or 
a supervisory manager process and are concurrently executed with the client 
and supervisory processes in a multitasking operating system. 
Consequently, the rate servers communicate with the client and supervisory 
manager processes via an inter-process communication (IPC) mechanism, 
such as a named pipe. In this system, a client program formulates a 
tokenized message with information about an item to be rated and passes 
the tokenized message to a rate server for a desired carrier via a named 
pipe. The operating system suspends execution of the client program and 
performs a context swap granting the rate server a time slice to compute the 
rate calculation. When activated, the rate server decodes the tokenized 
message, performs the rate calculation, tokenizes a response, and sends the 
tokenized response back to the client program through IPC. Finally, the 
operation system puts the rate server to sleep and executes another context 
swap to resume execution of the client program, which decodes the 
tokenized response. 

This system is resource intensive. For example, each concurrently 
executing rate server takes up an entry in a process table of the operating 
system, reducing the number of other processes that may be run 
concurrently. Moreover, there is processing overhead in tokenizing and 
decoding the messages used for the IPC mechanism as well as the 
overhead involved in the IPC mechanism itself. Another reason why the 
described system is resource intensive is that two context swaps are 



performed for every rate calculation. Context swaps are generally expensive 
in terms of processing time, because, for example, processor registers have 
to be saved and restored. 

Often, it is difficult to add support for new carriers to conventional 
logistic systems. For example, the system described by Nichoils et al. 
employs a supervisory server for managing one or more carriers, and 
corresponding rate server and rate administrator programs for handling tasks 
specific to a carrier. As disclosed in TABLE II of the Nichoils et al. reference, 
the supervisory server associates each carrier with a program identifier from 
a file called PROGISTI.H. The ".H" suffix of the file conventionally indicates 
a header file, which are used to hard-code the program identifiers at compile 
time into the supervisory server executable. Thus, to add support for a new 
carrier in such a system, the source code and header files for at least the 
supervisory server have to be modified. A new supervisory server 
executable program object must be compiled, distributed to the customer's 
site, and re-installed, often at a substantial monetary cost. 

There is a need for a carrier management system that facilitates the 
addition of new carriers without requiring reinstallation of program 
components. There also exists a need for a less resource-intensive, carrier 
management system that can calculate shipping rates for a plurality of 
carriers and allows ease of updating of individual carrier rates. 

These and other needs are met by the present invention, in which a 
carrier rate module contains sequences of item rating instructions for rating 
an item for a carrier and sequences of self-registration instructions for storing 
registration information about the carrier rate module in a registry. Since the 
carrier rate module includes self-registration code, the registration 
information is encapsulated in the new carrier rate module and can be 



transferred to the registry on installation. Thus, the information about 
available carriers is found in the registry and not hard-coded into a program, 
eliminating the requirement for redistributing software components to an 
existing installation. 

Accordingly, one aspect of the invention is a method of installing a 
carrier rate module on a computer system. The carrier rate module contains 
sequences of item rating instructions for rating an item for a carrier and self- 
registration instructions. The method includes making a computer readable 
medium bearing the carrier rate module accessible to the computer system. 
The self-registration instructions are executed causing the computer system 
to store registration information about the carrier rate module in a registry, 
e.g. a module identifier such as a pathname indicating how to load the carrier 
rate module. 

Preferably, the self-registration instructions are executed by executing 
a registration program with a parameter indicative of the carrier rate module. 
The carrier rate module is loaded into the executable space of the 
registration program. An entry point having a predefined name is identified 
and called to execute the sequences of self-registration instructions. 

In accordance with another aspect of the present invention, a carrier 
management system includes a registry containing registration information 
for carrier rate modules. The carrier rate modules contain self-registration 
instructions for storing the registration information in the registry and item 
rating instructions for rating an item for respective carriers. A carrier 
management librarian is configured to load a carrier rate module for a 
selected carrier based on the registration information stored in the registry. 

For example, the carrier management librarian when executed causes 
the computer system to access the registry to retrieve the module identifiers 



stored therein and load a selected carrier rate module into the executable 
space of a process executing the carrier management librarian based on the 
retrieved module identifiers. By loading the carrier rate modules directly into 
the executable space of an executing process, the process can avail .tself of 
functionality implemented in the modules without the overhead incurred for a 
separate process. Thus, entries in the process table of the operating system 
are saved and costly context swaps are avoided. Moreover, the requirement 
for IPC mechanisms for rating an item is eliminated because the earner rate 
module is loaded into the same executable space as the client process. 

Still another aspect of the invention is a computer-readable medium 
bearing a carrier rate module including item rating instructions arranged to 
rate items for a carrier and self-registration instructions. The self-registraton 
instructions are arranged to cause a computer to store registration 
information in a registry, e.g. a module identifier such as a pathname 
indicating how to load the carrier rate modu.e. The carrier rate module may 
be further configured to load a carrier data access module containing data 
access instructions for accessing carrier rate data stored in a non-volatile 
computer-readable medium, execute the data access instructions to retneve 
the carrier rate data, and execute the item rating instructions for rating .terns 
based on the carrier rate data. 

Additional objects, advantages, and novel features of the present 
invention will be set forth in part in the description that follows, given by way 
of example, and in part, will become apparent upon examination or may be 
learned by practice of the invention. 

The present invention is explained by way of example, and not by way 
of limitation, with reference to the figures of the accompanying drawings, .n 
which like reference numerals refer to similar elements and in wh.ch; 



FIG. 1 is a depiction of a computer system that can be used to 
implement the present invention. 

FIG. 2 is a depiction of a logistics system including a carrier manager 
according to an embodiment of the present invention. 

FIG. 3 shows an exemplary registry of supported carriers in 
accordance with an embodiment of the present invention. 

FIG. 4 is a flowchart illustrating the operation of self-registering a 
carrier rate module according to an embodiment of the present invention. 

FIG. 5(a) is a flowchart illustrating the operation of rating an item for 
one of the carriers managed by an embodiment of the present invention. 

FIG. 5(b) is a flowchart illustrating the operation of rating an item for 
one of the carriers managed by another embodiment of the present 
invention. 

FIG. 6 is a flowchart illustrating the operation of fetching carrier rate 
data according to an embodiment of the present invention. 

A system and a method for managing a plurality of carriers are 
described. In the following description, well-known structures and devices 
are shown in block diagram form in order to avoid unnecessarily obscuring 
the present invention. 

Hardware Overview 

FIG. 1 is a block diagram that illustrates a computer system 100 upon 
which an embodiment of the invention may be implemented. Computer 
system 100 includes a bus 102 or other communication mechanism for 
communicating information, and a processor 104 coupled with bus 102 for 
processing information. Computer system 100 also includes a main memory 
106, such as a random access memory (RAM) or other dynamic storage 
device, coupled to bus 102 for storing information and instructions to be 



executed by processor 104. Main memory 106 also may be used for storing 
temporary variables or other intermediate information during execution of 
instructions to be executed by processor 104. Computer system 100 further 
includes a read only memory (ROM) 108 or other static storage device 
coupled to bus 102 for storing static information and instructions for 
processor 104. A storage device 110, such as a magnetic disk or optica, 
disk is provided and coupled to bus 102 for storing information and 
instructions. Common examples of computer system 100 include persona, 
computers, workstations, minicomputers, servers, and mainframes. 

Computer system 100 may be coupled via bus 102 to a display 112, 
such as a cathode ray tube (CRT), for displaying information to a computer 
user An input device 114, including alphanumeric and other keys, » 
coupled to bus 102 for communicating information and command se.ect.ons 
to processor 104. Another type of user input device is cursor control 116, 
such as a mouse, a trackball, or cursor direction keys for communicating 
direction information and command selections to processor 104 and for 
controlling cursor movement on display 112. This input device typically has 
two degrees of freedom in two axes, a first axis (e.g., x) and a second ax.s 
(e.g., y), that allows the device to specify positions in a plane. 

The invention is related to the use of computer system 100 for 
managing carriers. According to one embodiment of the invention, earner 
management is provided by computer system 100 in response to processor 
104 executing one or more sequences of one or more instructions conta.ned 
in main memory 106. Such instructions may be read into main memory 106 
from another computer-readable medium, such as storage device 110. 
Execution of the sequences of instructions contained in main memory 106 
causes processor 104 to perform the process steps described herein. One 
or more processors in a multi-processing arrangement may also be 
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employed to execute the sequences of instructions contained in main 
memory 106. in alternative embodiments, hard-wired circuitry may be used 
in place of or in combination with software instructions to implement the 
invention. Thus, embodiments of the invention are not limited to any specific 
5 combination of hardware circuitry and software. 



The term "computer-readable medium" as used herein refers to any 
medium that participates in providing instructions to processor 104 for 
execution. Such a medium may take many forms, including but not limited 
to, non-volatile media, volatile media, and transmission media. Non-volatile 
media include, for example, optical or magnetic disks, such as storage 
device 110. Volatile media include dynamic memory, such as main memory 
106. Transmission media include coaxial cables, copper wire and fiber 
optics, including the wires that comprise bus 102. Transmission media can 
also take the form of acoustic or light waves, such as those generated during 
radio frequency (RF) and infrared (IR) data communications. Common forms 
of computer-readable media include, for example, a floppy disk, a flexible 
disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, 
DVD, any other optical medium, punch cards, paper tape, any other physical 
medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH- 
EPROM, any other memory chip or cartridge, a carrier wave as described 
hereinafter, or any other medium from which a computer can read. 



Various forms of computer readable media may be involved in 
carrying one or more sequences of one or more instructions to processor 
104 for execution. For example, the instructions may initially be borne on a 
magnetic disk of a remote computer. The remote computer can load the 
instructions into its dynamic memory and send the instructions over a 
telephone line using a modem. A modem local to computer system 100 can 
receive the data on the telephone line and use an infrared transmitter to 
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convert the data to an infrared signal. An infrared detector coupled to bus 
1 02 can receive the data carried in the infrared signal and place the data on 
bus 102. Bus 102 carries the data to main memory 106, from which 
processor 104 retrieves and executes the instructions. The instructions 
5 received by main memory 106 may optionally be stored on storage device 
1 1 0 either before or after execution by processor 1 04. 

Computer system 100 also includes a communication interface 118 
coupled to bus 102. Communication interface 118 provides a two-way data 

io communication coupling to a network link 120 that is connected to a local 
network 122. For example, communication interface 118 may be an 
integrated services digital network (ISDN) card or a modem to provide a data 
communication connection to a corresponding type of telephone line. As 
another example, communication interface 118 may be a local area network 

15 (LAN) card to provide a data communication connection to a compatible 
LAN. Wireless links may also be implemented. In any such implementation, 
communication interface 118 sends and receives electrical, electromagnetic 
or optical signals that carry digital data streams representing various types of 
information. 

20 

Network link 120 typically provides data communication through one 
or more networks to other data devices. For example, network link 120 may 
provide a connection through local network 122 to a host computer 124 or to 
data equipment operated by an Internet Service Provider (ISP) 126. ISP 126 

25 in turn provides data communication services through the worldwide packet 
data communication network, now commonly referred to as the "Internet" 
128. Local network 122 and Internet 128 both use electrical, 
electromagnetic or optical signals that carry digital data streams. The signals 
through the various networks and the signals on network link 120 and 

3 0 through communication interface 118, which carry the digital data to and 
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from computer system 100, are exemplary forms of carrier waves 
transporting the information. 

Computer system 100 can send messages and receive data, including 
program code, through the network(s), network link 120, and communication 
interface 118. In the Internet example, a server 130 might transmit a 
requested code for an application program through Internet 128, ISP 126, 
local network 122 and communication interface 118. In accordance with the 
invention, one such downloaded application provides for carrier management 
as described herein. 

The received code may be executed by processor 104 as it is 
received, and/or stored in storage device 110, or other non-volatile storage 
for later execution. In this manner, computer system 100 may obtain 
application code in the form of a carrier wave. 

System Overview 

Referring to FIG. 2, depicted is a diagram of a logistics system 200, 
which provides a client application 210 with item rating functionality for a 
supported carrier, according to one embodiment of the invention. Client 
application 210 typically is an executable program that provides an interface 
for interacting with a user and implements high-level logistics functionality. 
For example, the client application 210 may be a shipping application, 
responsible for grouping letters, packages, parcels, bulk goods, 
commodities, or any other transportable item into shipments to be shipped 
by a carrier. Some client applications may implement or utilize functions for 
handling shipping manifests, printing labels, controlling inventory, load 
balancing, applying postage, and the like. In the system architecture 



illustrated in FIG. 2, at least some of the item rating functionality is 
coordinated through carrier management librarian 220. 

Carrier management librarian 220 is a module containing instructions 
for managing a plurality of supported carriers. As described in more detail 
hereinafter, carrier manager librarian 220 is configured to read a system 
registry 230 of supported carriers and cause item rating instructions 244 of a 
carrier rate module 240 corresponding to a selected carrier to be executed. 
Although the carrier manager librarian 220 can be statically linked into the 
client application 210, it is preferably dynamically linked into the cl.ent 
application 210. Dynamic linking a module involves loading at run-time the 
module into the executable space of an executing process, e.g. a portion of 
virtual memory allocated by the operating system for executing a process 
such as client application 210. Common examples of these modules include 
dynamic link library (DLL) modules, shared libraries, and OLE™ and 
ActiveX™ controls supported by Microsoft Corp. 

By loading the carrier manager librarian 220 directly into the 
executable space of an executing process, the client application 210 can 
avail itself of functionality implemented in the module without the overhead 
incurred for a separate process. Thus, entries in the process table of the 
operating system are saved and costly context swaps are avoided. OLE and 
ActiveX controls, sometimes called "OCX," allow for late binding of funct.on 
calls remote execution in a distributed or networked environment, and 
interfacing with the Internet or World Wide Web. A re-entrant version of 
carrier manager librarian 220 may even be linked and loaded into one 
executing client application 210 and set up to be invoked by another 
separately executing client process, e.g. by IPC mechanisms or procedure 
calls. 
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Many operating systems such as Windows 95™ and Windows NT™, 
available from Microsoft Corp., provide a resource called a system registry to 
contain operational information for software systems. In accordance with 
one embodiment of the present invention, carrier information and settings 
are stored in the system registry. The present invention is not limited to 
storing information in a specially provided system registry. Indeed, any file 
can be used as registry if it contains a list of carriers identified by a name or 
token and identifiers of corresponding carrier rate modules 240 in a one-to- 
one association. For example, such a registry may be implemented on 
UNIX™ systems or MS-DOS™ by a configuration file. 

Exemplary carrier information stored in a system registry 230 
according to one embodiment of the present invention is illustrated in FIG. 3. 
In a hierarchically organized system registry 230, the carrier information is 
preferably placed under one registration key 300, which includes the 
vendor's name, e.g. Pitney Bowes, for uniqueness purposes. Under 
registration key 300 is recorded a version ID 310 for use in detecting the 
presence of incompatible versions of the carrier management librarian 220. 
Under a "carriers" subkey 320 of registration key 300 is a list of carriers 
supported in an installation of carrier manager librarian 220. The list includes 
entries 322, 322', etc., identified by a token 324 and carrier registration data 
326. The value of the token 324 is preferably a short string (within eight 
characters) denoting a carrier. Common token values can include "USPS" 
for the United States Postal Service, "YELL" for the Yellow Freight System, 
Inc., "UPS" for the United Parcel Service, etc. 

The carrier registration data 326 in each entry 322 under the carriers 
subkey 320 includes an identifier of a corresponding carrier rate module 240, 
which contains instructions for rating an item according to business rules and 
rate data for a carrier. The value of the identifier depends on how the carrier 



14 



rate modules 240 are implemented. If the carrier rate modules 240 are 
implemented as DLLs or other run-time loadable libraries, then the identifier 
contains the full pathname of the library. On the other hand, if the carrier 
rate modules 240 are implemented as OLE or ActiveX controls, then the 
identifier can be a class identifier, such as a guid (globally unique identifier), 
128-bit hexadecimal value. 

Other information stored in the carrier registration data 326 may 
include the full name of the carrier, the carrier type, the installation date, and 
the effective date. If the carrier token is kept short as preferred, then it is 
desirable to store the full name of the carrier in the carrier registration data 
326. The carrier type can be set to "LTL" for bulk goods shipped on a 
truckload, to "PKG" for ground carriers, "EXP" for air carriers, etc. The 
carrier type allows other code modules developed for a class of carriers, e.g., 
to identify relevant carriers from the list of carriers under subkey 320. For 
example, a module (not shown) for handling the shipment of commodities 
can produce a bill of lading for LTL or TL shipments for carriers identified as 
LTL type in the carrier registration data 326. The pathname 330 for such a 
bill of lading module may be recorded under registration key 300. As 
another example A pathname 340 for a package shipment module (not 
shown) handles ground shipments for relevant carriers. These modules allow 
for the abstraction and encapsulation of common functionality for carrier 
types in a single code module according to sound principles of software 
engineering. 

The installation date indicates the date in which the carrier rate 
module was installed, and the effective date indicates a possibly future date 
at which the carrier rate calculations are valid. As evident to those skilled in 
the art, other information relating to a specific carrier can be stored in each 
entry 322 depending on the particular implementation environment. In fact, 



most of the information other than the identifier of the corresponding carrier 
rate module 240 may be omitted when not necessary in the implementation 
environment. As depicted in FIG. 3, the carrier registration data 326 is 
stored as a list of keywords and data, but other structures of organizing data, 
e.g. fixed-width or variable width fields, may be employed. 

Also stored under registration key 300 is administrative data 350, 
useful for an installation of logistics system 200. The particular information 
stored under administrative data 350 will vary from implementation to 
implementation and will be evident to those skilled in the art. For example, 
pathname data for a data access module 270, described in more detail 
hereinbelow, may be recorded under administrative data 350. 

Referring back to FIG. 2, included in the logistics system 200 is a 
plurality of carrier rate modules 240a, 240b, and 240c, collectively denoted 
by the numeral 240. Although three carrier rate modules 240 are shown, it is 
evident that any number of carrier rate modules 240 may be installed on a 
logistics system 200 and that the particular number installed depends on the 
customer environment. Only the carrier rate modules 240 for those carriers 
desired by a user need be installed. For example, at site in which only 
packages are sent, the carrier rate modules 240 for LTL rating does not have 
to be installed. 

Each carrier rate module 240 is configured to be loaded at run-time in 
the executable space of an executing process. Accordingly, the carrier rate 
modules 240 are preferably implemented with such techniques as DLLs, 
shared libraries, or by other kinds of dynamic linking, such as OLE and 
ActiveX controls. Each carrier rate module 240, e.g. carrier rate module 
240a, contains item rating code 244a and preferably self-registry code 242a. 



As described in more detail hereinafter, the self-registry code 242a, 
invoked by installation program 260, includes instructions for creating an 
entry in registry 230 with the information for the corresponding carrier. The 
item rating code 244a of a carrier rate module 240a contains instructions for 
rating an item based on business rules for the corresponding carrier and 
carrier rate data 250a. Accessing the carrier rate data 250a and 250b by the 
respective item rating code 250a and 250b may occur directly as for carrier 
rate module 240a, or, as illustrated for carrier rate module 240c, through a 
data access module 270. The data access module 270 is also configured to 
be loaded at run-time in the executable space of an executing process, e.g. 
as a DLL shared library, OLE control, or any other dynamic linking or load.ng 
technique, from information recorded in administrative data 350 in system 
registry 230. 

In | iiiinn i Mm ^rr°r P ate Mnriule 

Support for a new carrier is facilitated by incorporating self-registration 
instructions 242a along with the item rating code 244a within a new carrier 
rate moduie 240a. as illustrated by step 400 in FIG. 4. The self-registration 
code 242a includes instructions for creating a new entry 322' under the 
carriers subkey 320 in system registry 230. Specially, new entry 322' 
includes at least a earner identifier, e.g. a short carrier token, for the 
associated carrier and a module identifier indicating how to load the new 
carrier rate module 240a. 

The particular value of the module identifier depends on the 
im p,ementationofnewcarrierrate module 240a. For example, if new earner 
rate module 240a is a DLL, then the module identifier is a full pathname of 
the DLL As another example, a module identifier for carrier rate modules 
implemented by OLE contro.s would be a Program Identifier or PROGID, e.g. 



a globally unique OLE name. The self-registration code 242a is configured 
to write other installation information, for example, the installation date, an 
effective date, a full description of the carrier, etc., as required or desired by 
the particular operating environment. 

in step 402 the new carrier rate module 240a is made available to a 
target computer system, e.g. by storing it in a computer-readable medium 
accessible to the target computer system. For example, a CD-ROM 
containing the new carrier rate module 240a may be loaded into a CD-ROM 
drive of the target computer system. As another example, the new earner 
rate module 240a may be downloaded from an Internet site, e.g. by FTP, 
TFTP or other protocol. When the new carrier rate module 240a is made 



available to the target computer system, the self-registration instructions 
242a are executed to register the new carrier rate module 240a. 

Preferably, an installation script or program distributed on the same 
computer-readable medium storing the new carrier rate module 240a 
incudes instructions for causing self-registration code 242a to be executed. 
The installation program may execute a standard registration program 270, 
eg regsvr32.exe on a Microsoft Windows™ system with a command-hne 
parameter indicating the new carrier rate module 240a (step 404). For 
example, the command-line parameter may be the pathname of the new 
carrier rate module 240a. 

The registration program is configured to dynamically load and link the 
carrier rate module 240a specified by its command-line parameter (step 406) 
and invoke a function in the loaded carrier rate module 240a wrth a 
predefined name, e.g. "Dl.RegisterServer ,« (step 408). Ca.Hng this function 
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causes the self-registration code 242a to be executed, resulting in the 
creation of a new entry in the system registry 230 (step 410). In particular, 
the self-registration code 242a is configured to write installation information, 
including a carrier identifier for the new carrier, a module identifier indicating 
5 how to load the carrier rate module 240a, as well as other information such 
as the installation date, an effective date, a full description of the carrier, etc. 

After self-registration, the new carrier rate module 240a is now 
available for use by carrier manager librarian 220 or any other process 
10 examining system registry 230 for using in rating items for its associated 
carrier. 
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patina an ltp»m for a Selected Carrier 

Referring to FIG. 5(a), the operation of carrier manager librarian 220 
according to one embodiment of the present invention is illustrated. When 
the client application 210 is executed by a user, it is configured to call an 
initialization routine in the carrier management module 220. During 
initialization, carrier manager librarian 220 accesses the system registry 230 
in step 502 to retrieve information about carrier rate modules installed and 
registered in the logistics system 200. 

Specifically, the carrier manager librarian 220 reads carrier tokens 322 
stored under the carriers subkey 320 in the registry 230 (step 504). For each 
carrier token read, the carrier manager librarian 220 retrieves the associated 
module identifier for the corresponding carrier rate module, e.g. a full 
pathname of a carrier rate DLL. Using the module identifier, the carrier 
manager librarian 220 causes the carrier rate module to be loaded into the 
executable space of the process executing the carrier manager librarian 220 
(step 506). Many operating systems return a handle after loading a module 
such as a DLL, shared library, or other dynamically linked code segment for 
access to the functions contained therein. Accordingly, step 508 is 
performed in which the returned module handle is saved along with the 
carrier token in a data structure such as a linked list. A handle is a generic 
term for a pointer, an integer, or other data type that identifies an object or 
resource manipulated by operating system routines. As evident to those in 
the art, the use of a linked list is not crucial, since any data structure that 
allows a set of associated items may be used. For example, alternative 
implementations of carrier manager librarian 220 may employ such data 
structures as arrays of records/structures, parallel arrays, stacks, queues, 
heaps, trees, skip lists, etc. 
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After initialization, control passes back to the client application 210 
that loaded the carrier manager librarian 220 or called its initialization routine. 
When the client application 210 later proceeds to rate an item to be shipped, 
the client application 210 invokes the carrier manager librarian 220 with a 
5 parameter, e.g. a carrier token, to specify the carrier for which the item is to 
be rated. In response, carrier manager librarian 210 performs step 510 in 
which the linked list or other data structure is inspected for an entry 
corresponding to the carrier token parameter. If the carrier token is found, 
then the associated module handle is used to obtain an entry point in the 

io previously loaded carrier rate module (step 512). Typically, the entry point is 
expressed as a pointer to a function, sometimes called a Far Pointer or 
FARPTR, which can be called to execute instructions in the carrier rate 
module (step 514). The carrier manager librarian 220 may pass the entry 
point back to client application 210 for later invocation or call the item rating 

15 instructions directly. The item rating instructions, when executed, rate the 
item for delivery according to the appropriate business rules and carrier rate 
data. 

When a carrier rate module, e.g. carrier rate module 240c in FIG. 2, is 
20 configured to use a run-time loadable data access module 270 as an 
interface for retrieving carrier rate data 250c, one embodiment of the present 
invention performs the steps illustrated in FIG. 6. In step 600, the data 
access module 270 is loaded into the executable space of the executing 
process, e.g. client application 210. This step may occur when client 
25 application 210 is first executed or deferred until necessary to reduce the 
start up time of client application 210 at an additional coding expense. Since 
data access module 270 contains instructions for fetching carrier rate data, 
those instructions are executed to fetch the carrier rate data (step 602). 
Consequently, the item rating instructions of the carrier rate module 240c 
3 0 can use the carrier rate data for rating the item (step 604). By isolating the 



carrier rate data access instructions into a separately loadable module, the 
format and design of the carrier rate data file 250c may be changed without 
necessitating a modification to the carrier rate module 240c. 

It may be appreciated that all the registered carrier rate modules are 
loaded once during initialization time in the embodiment illustrated in FIG. 
5(a). This approach may result in an increased start up time for the carrier 
manager librarian 220. If it is desired to reduce this start up time, then the 
carrier manager librarian 220 can be configured to load the carrier rate 
modules on an as-needed basis, as illustrated in FIG. 5(b). In this 
embodiment, the registry is accessed (step 502) and each carrier is iterated 
(step 504) as described hereinabove. However, the body of the loop saves 
the carrier token and the associated module identifier, e.g. either a full 
pathname or an OLE, accessed from registry 230 (step 508') in the linked list 
or other data structure. After all the carriers registered in the registry 230 
have been processed, control passes back to the client application 210. 

When the client application 210 calls the carrier manager librarian 220 
with a carrier token as a parameter for rating an item or obtaining a entry 
point of a routine for rating the item, the carrier manager librarian 220 at step 
510' inspects the linked list for an entry containing that carrier token. If there 
is such an entry, then the carrier rate module is loaded into the executable 
space based on the module identifier contained in the identified entry (step 
506), returning a module handle. A flag can be included in the entry to avoid 
loading the carrier rate module more than once in a, session. Then, an entry 
point is obtained from the module handle of the previously loaded carrier rate 
module (step 512). The carrier manager librarian 220 may then pass a 
function pointer to the entry point back to client application 210 for later 
invocation or call the item rating instructions directly module (step 514). 



Use of carrier rate modules 240, which can be distributed separately 
from client applications 210, enables the business rules and carrier rate data 
for individual carriers to be updated without requiring the recomp,lat,on, 
relinking, or redistribution of the client applications. Sine* each earner rate 
m0 dule 240 is loaded into the executable space of an executing process, 
e o client application 210, this approach is less resource intensive than the 
approach o, executing the carrier rate modules as separate programs that 
communicate with the Cent program via an IPO mechanism. For example^ 
dynamically loadable modules do no. use operating system resources, such 
as an entry in a process table. As another example, communion 
between client application 210 and carrier rate module 240 is accomplished 
thr0 ugh a function call, without expensive context swaps or —,on of 
the parameters to an item rating function. 

Use of a registry 230 in conjunction with a carrier manager l.branan 
modu ,e 220 allows new carrier rate modules 240 to be installed wi*ou, 
quiring reinstallation o, client application 210 or any other program. S,nce 
each carrier rate module 240 includes self-registration code 242 a. 
predenned location, the registration information is encapsulated in the new 
arrier rate module and transferred to a registry 230 on ,nsta„at,on. 
Therefore, the Information about which carriers are available a, a customer, 
found in the registry and not hard-coded into a program. Consequently, the 
need to redistribute software components to an existing ,ns«alla„on „ 
removed. 
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Claims: 

1 . A method of installing a carrier rate module for rating an item for a 
carrier on a computer system, said method comprising the computer- 

5 implemented steps of: 

(a) making a computer readable medium bearing the carrier rate module 
accessible to the computer system; and 

(b) executing self-registration instructions contained in the carrier rate 
module, causing the computer system to perform the step of storing 

io registration information about the carrier rate module in a registry. 

2. The method of Claim 1, wherein the step of storing registration 
information about the carrier rate module in a registry includes the step of 
storing in the registry a carrier identifier indicative of the carrier in one-to-one 

15 association with a module identifier indicative of how to load the carrier rate 
module. 

3. The method of Claim 2, wherein the step of storing a carrier identifier 
and a module identifier includes the step of storing a pathname of the carrier 

20 rate module in the registry. 

4. The method of Claim 1, 2 or 3, wherein the step of executing the 
sequences of self-registration instructions includes the computer- 
implemented steps of: 

25 (a) executing a registration program with a parameter indicative of the 
carrier rate module; 

(b) loading the carrier rate module into the executable space of the 
executing registration program; 

(c) identifying an entry point having a predefined name for the sequences 
30 of self-registration instructions; and 
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(d) calling the entry point to execute the sequences of self-registration 
instructions. 

5. A carrier management system, comprising: 

(a) a plurality of carrier rate modules for containing self-registration 
instructions and item rating instructions arranged to rate an item for 
respective carriers of a plurality of carriers; 

(b) a registry for recording registration information about the carrier rate 
modules; and 

(c) a carrier management librarian module for loading a selected carrier 
rate module corresponding to a carrier specified by a client application based 
on registration information recorded in the registry; wherein, the self- 
registration instructions of the selected carrier rate module, when executed, 
cause a computer system to store registration information for the selected 
carrier rate module in the registry. 

6. The carrier management system of Claim 5, wherein the self- 
registration instructions of a selected carrier rate module are such that, when 
executed, they further cause the computer system to store in the registry a 
carrier identifier indicative of the carrier in one-to-one association with a 
module identifier indicative of how to load the selected carrier rate module. 

7. The carrier management system of Claim 5 or 6, wherein the carrier 
management librarian module is arranged, when executed, to cause the 
computer system to: 

(a) access the registry to obtain the carrier identifiers in a one-to-one 
association with the module identifiers; 

(b) load a selected carrier rate module corresponding to the selected 
carrier, based on the module identifiers accessed in the registry, into the 
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executable space of a the client application executing the carrier 
management librarian module; and 

(c) identify an entry point of the item rating instructions in the selected 
carrier rate module based on an associated module identifier corresponding 
to the selected carrier. 

8. The carrier management system of Claim 5, 6 or 7, wherein the carrier 
management librarian module is further configured to load all the carrier rate 
modules corresponding to the carriers into the executable space of the client 
application based on all the module identifiers recorded in the registry. 

9. The carrier management system of any one of Claims 5 to 8, wherein 
the carrier management librarian module is further configured to: 

(a) identify the selected carrier rate module from among the plurality of 
carrier rate modules based on an identifier specified by the client application; 
and 

(b) load the selected carrier rate module after identifying the selected 
carrier rate module. 

10. The carrier management system of any one of Claims 5 to 9, wherein 
the carrier management librarian module is further configured to dynamically 
link the carrier rate module into the executing client application. 

11. The carrier management system of any one of Claims 5 to 1 0, further 
comprising a carrier rate data access module for containing data access 
instructions arranged to access carrier rate data stored in a file on a non- 
volatile computer readable medium; wherein at least one of the carrier rate 
modules is configured to: 

(a) load the carrier rate data access module; 
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(b) execute the data access instructions for accessing the carrier rate 
data for the corresponding carrier; and 

(c) execute the item rating instructions for rating the item based on the 
carrier rate data. 

5 

12. A computer-readable medium bearing a carrier rate module, said 
carrier rate module comprising: 

(a) item rating instructions arranged to cause a computer system to rate 
items for a carrier; and 
io (b) self-registration instructions arranged to cause a computer system to 
store registration information for the carrier rate module in a registry. 

13. The computer-readable medium of Claim 12, wherein the self- 
registration instructions are further arranged to cause the computer system 

15 to store in the registry a carrier identifier indicative of the carrier in one-to-one 
association with a module identifier indicative of how to load the carrier rate 
module. 

14. The computer-readable medium of Claim 12 or 13, wherein the self- 
20 registration instructions are further arranged to cause the computer system 

to store a pathname of the carrier rate module in the registry. 

15. The computer-readable medium of Claim 12, 13 or 14, wherein the 
carrier rate module further includes instructions arranged to cause the 

25 computer system to: 

(a) load a carrier rate data access module containing data access 
instructions arranged to access carrier rate data stored in a file on a non- 
volatile computer readable medium; 

(b) execute the data access instructions for accessing the carrier rate 
3 o data for the corresponding carrier; and 



(c) execute the item rating instructions for rating the item based on the 
carrier rate data. 

16. A method of installing a carrier rate module for rating an item for a 
carrier on a computer system, substantially as hereinbefore described with 
reference to the accompanying drawings. 

17. A carrier management system substantially as hereinbefore described 
with reference to the accompanying drawings. 

18. A computer-readable medium substantially as hereinbefore described 
with reference to the accompanying drawings. 



